home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9701 / 000032_owner-urn-ietf _Thu Jan 30 17:55:17 1997.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA17794 for urn-ietf-out; Thu, 30 Jan 1997 17:55:17 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA17785 for <urn-ietf@services.bunyip.com>; Thu, 30 Jan 1997 17:55:14 -0500
  3. Received: from ritig1.rit.reuters.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA18241  (mail destined for urn-ietf@services.bunyip.com); Thu, 30 Jan 97 17:55:11 -0500
  5. Received: from ritig4.rit.reuters.com by ritig1.rit.reuters.com; (5.65v3.2/1.1.8.2/14Sep94-0947PM)
  6.     id AA03945; Thu, 30 Jan 1997 16:48:12 -0500
  7. Received: from mr.rit.reuters.com by RITIG4.RIT.REUTERS.COM (PMDF V5.1-5 #7805)
  8.  id <01IETZQ0HNS000024E@RITIG4.RIT.REUTERS.COM>; Thu, 30 Jan 1997 17:53:39 EST
  9. Received: with PMDF-MR; Thu, 30 Jan 1997 22:53:50 +0000 (GMT)
  10. Mr-Received: by mta REC.MUAS; Relayed; Thu, 30 Jan 1997 22:53:50 +0000
  11. Mr-Received: by mta RE6; Relayed; Thu, 30 Jan 1997 22:53:53 +0000
  12. Mr-Received: by mta RITIG4; Relayed; Thu, 30 Jan 1997 22:53:26 +0000
  13. Disclose-Recipients: prohibited
  14. Date: Thu, 30 Jan 1997 22:53:50 +0000 (GMT)
  15. From: Ian Higgs +44 171 542 8595 <IAN.HIGGS@reuters.com>
  16. Subject: Re: [URN] Fragment references.
  17. In-Reply-To: <199701302157.NAA01386@ishtar.fsc.fujitsu.com>
  18. To: Terry Allen <tallen@fsc.fujitsu.com>
  19. Cc: URN Mailing list <urn-ietf@bunyip.com>
  20. Message-Id: <5650532230011997/A33094/RE6/11B1F5B52F00*@MHS>
  21. Autoforwarded: false
  22. Mime-Version: 1.0
  23. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  24. Importance: normal
  25. Priority: urgent
  26. Sensitivity: Company-Confidential
  27. Ua-Content-Id: 11B1F5B52F00
  28. X400-Mts-Identifier: [;5650532230011997/A33094/RE6]
  29. Hop-Count: 2
  30. Sender: owner-urn-ietf@services.bunyip.com
  31. Precedence: bulk
  32. Reply-To: Ian Higgs +44 171 542 8595 <IAN.HIGGS@reuters.com>
  33. Errors-To: owner-urn-ietf@bunyip.com
  34.  
  35. Sorry to confuse you
  36. - I may be crossing threads and discussing two things at once.
  37.  
  38. ] This assumes that a "relative URN" is a "fragment reference."  That's
  39. ] not obvious.
  40.  
  41. I see them as two very different things:
  42.     fragment refs are "#something"
  43. but
  44.     relative refs are "../something".
  45.  
  46. i.e.
  47.     fragment refs are 'pointers' within the current resource
  48.     and (probably) do not imply a fetch
  49. but
  50.     relative refs are refs to another resource and do imply a fetch.
  51.  
  52. ] I would say that relative URNs have not been specified.
  53.  
  54. Has everybody already agreed that a URN is NOT a form of URI
  55. and the "/" character does NOT imply a hierarchy as stated in RFC1630?
  56. I think that I missed that.
  57. If so then there can be no such thing as relative URNs and all URNs
  58. might as well be 32 digit random numbers (for which there IS a case).
  59.  
  60. /Ian Higgs
  61.